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BACKGROUND OF THE INVENTION 

1. FIELD OF THE INVENTION 

The present invention relates to automotive telemetry protocols and their use in Intelligent 
5 Transportation Systems. 

2. DESCRIPTION OF THE RELATED ART 

Conventionally, vehicles have been known to exchange data with' a diagnostic computer 
10 . system (such as in a fepak garage) ov^ a hardwired or mfrared data link, or a regulatory 
computer system (such as an electronic toll highway) by a data link using a low power 
transponder. 

More sophisticated vehicular telemetry for commeicial fleets has been made possible in 
15 the last several years through both terrestrial and satellite RF packet networks. In these 
vehicular telemetry systems, vehicle sensor data can be transpdrted over wireless data 
links to a computer that is programmed to monitor and record automotive phenomena and 
to support database systems for vehicular maintenance, without the need for the vehicle to 
be in a particular service bay for example. However, these systems are relatively 
20 expensive to operate. 

A considerable amount of research is being dedicated to developing feasible Intelligent 
Vehicle Highway Systems (IVHS) which are computer-assisted methods to manage 
highway infrastmctures, synchronize trafSc lights, measure traffic flow, to alert drivers to 
25 ongoing trafSc conditions through electronic billboards and other innovations aimed at 
improving the quality and efiBciency of road transportation systems for vehicles. 

The California Air Resources Board (CARB) has been a leader in establishing standards 

for monitoring vehicle emissions. A recent CARB initiative, known as OBD-m, is the 

30 third generation of on-boaid diagnostic requirements, calling for an emissions regulatory 

agency to retrieve, remotely, diagnostic data from vehicles, thereby avoiding the need for 

a visit to a clean air inspection station. In one pilot program, a low-power transponder was 

used on each vehicle, csqpable of transferring data between the vehicle and a roadside 
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receiver. Of course, in order for the OBD-III pioposal to proceed^ each vehicle mustHave 
a system capable of collecting and dispatching tiie requested data through the transponder. 
CARB is actively reviewing currently available technologies and is surveying the 
telecommunications industry to see what future equipment is planned The operating 
S platforms tested thus &r by CARB have been relatively cumbersome and have limited 
capability to be used for otiier data exchange needs in the future. There is interest in 
finding a platform that will be economical to operate in order to minimize the financial 
burden placed on the consumer to implement the proposal. 

10 Morever^ it would be desirable for the chosen platform to be capable of doing more tiian 
just sending diagnostic information to a clean air agency. Both the telecom and auto 
industries are looking at ways to utilize the tremendous business opportunities of reaching 
urban commuters in their vehicles while they devote several hours each day to their 
commute. 

15 

Vehicular trafific has become a major problem for urban plaimers. With land values 
skyrocketing and land-use issues becoming more of a concern, planners are looking for 
ways of getting more vehicles through existmg commuter arteries as an alternative to 
expanding them. It is also known that the actual volume of traffic handled by a 
20 thoroughfare plummets when traffic becomes congested Therefore, it would be desirable 
to have vehicles which are capable of exchanging data with themselves as a way to control 
such things as safe driving distances to avoid collisions and exchanging data with traffic 
monitoring systems to control such things as driving speeds. 

25 It is therefore an object of the present invention to provide an improved platform for 
vehicular telemetry. 

It is a further object of the present invention to provide an improved vehicular telemetry 
system which is relatively inexpensive^ yet capable of excbangmg a range of useful data 
30 through a data communications syst^ between a vehicle and a fixed location. 

It is still a further object of the present invention to provide a vehicle communications 

system in which tiie vehicles therein are each capable of communicating both through a 

3 
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SUMMARY OF THE INVENTION 

5 In one of its a^ects, the present invention provides a method of conveying vehicle 
operation data fix>m a vehicle to a remote monitoring recipient, comprising the steps of: 

- establishing a data link between the vehicle and the remote monitoring 
recipient; 

10 

- collecting vehicle operation data from data sources in the vehicle; 

- packaging the vehicle operation data m a data packet using protocol derived 
from SNMP; and 

15 

- conveying the data packet over the data link. 

In another of its aspects, the present invention provides a method of conveying vehicle 
operation data from a vehicle server to a remote monitoring client, comprising the steps of: 

20 

- establishing a data link between the vehicle and the remote monitoring client; 

- collecting vehicle opemtion data from data sources in the vehicle server; 

25 - packagmg the data in a protocol data unit having a protocol data unit payload, 

the payload uicluding a plurality of VARIABLE BINDING fields, each 
VARIABLE BINDING field havmg an OBJECT IDENTIFIER field of two 
bytes, a VALUE TYPE field of one byte and a VARIABLE BINDING value 
of a size according to the VALUE TYPE field ; and 

30 

- conveying the protocol data unit over the data link. 

In still another of its aspects, the present invention provides a method of collecting vehicle 

4 
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operation data from a vehicle for later transmission to a remote monitoring recipient ili a 
manner to minimize the bandwidth requirements for the later transmission, comprising the 
steps of: 

5 - providing a vehicle on-board computing device; 

- providmg a number of data acquisition modules, each to measure one or more 
operating characteristics of the vehicle, the operatmg characteristics 
corresponding to current values of a set of manc^ed objects; 

10 . 

- interfacing the vehicle on-board computing device with each of the data 
acquisition modules; 

- configuring the vehicle on-board computing device to: 

15 

a) form a diagnostic information base for receiving and storing values for 
each of the managed objects from each of the corresponding data 
acquisition modules; 

20 b) assemble an event report based on information contained in the 

diagnostic information base; and 

c) package the event report m a protocol data unit according to an SNMP- 
dorived protocol. 

25 

Preferably, the operating characteristics mclude such things as GPS position, engme 
speed, road speed, odometer, or engme tempa:ature, or an OBD-II parameter related to 
vehicle emissions. One OBD-II parameter is misfire detection, though others are also 
applicable, such ais the O2 sensor. 

30 

In one embodiment, the present invention further comprises the stq> of enabling the 
vehicle on-board computing device to: 

5 
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a) establish a data link with the remote monitoring recipient; and 

b) convey the piotocol data imit over the data link* 

S The collecting and packaging and conveying steps may occur at the same or they may 
occur at different times. The computing device, in this case, may be enabled to collect 
data at regular or irregular intervals and accumulate some types of data for later 
transmission, such as distance travelled^ or other types of data for inmsediate transmission, 
such as a current GPS position or an exceeded regulatory threshold. Alternatively, there 
1 0 may be some instances where the computing device is enabled to convey the protocol data 
unit over a wired or other data link. 

Preferably, the method includes the step of enabling the remote monitoring recipient to 
issue a GET protocol data imit to retrieve the current values for a specific set of managed 
IS objects from the vehicle on-^board computing device. In this case, the remote monitoring 
recipient is enabled to wait for an acknowledgement to the GET protocol data unit by the 
vehicle on-board computing device. 

Preferably, the method includes the step of enabling the vehicle on-board computing 
20 device to issue a TRAP protocol data unit to report a vehicular event 

Preferably, the method includes the step of enabling the vehicle on-board computing 
device to: 

25 a) store threshold values or areportmg interval for each vehicular event; and 

b) issue each IHAP protocol data uni^ either wh^ a threshold value has been 
exceeded or at a corresponding reporting interval. 

30 In this case, the TRAP protocol data unit may report such vehicle reports as GPS position 
and the like. 

Preferably, the method includes the step of issumg an INFORM protocol data unit fiom 

6 
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the vehicle to report an exceptional vehicular event The method, m diis case, preferably 
includes the step 6f enabling the vehicle on-board computing device to: 

a) store any one of a plurality of specificadons for exceptional vehicular events in 
S the diagnostic information base, including one or more regulatory exceptions, 

maintenance exceptions or operational exceptions; and 

b) issue the INFORM protocol data unit when any one of the specified events 
occurs* 

10 . 

In one embodiment, the diagnostic information base contdns a specification of what 
constitutes the occurrence of an "event'' and not the event itself When the event occurs, a 
record of the event is made in a transmission queue and remains there until an 
acknowledgement message (in this case a RESP message) is received by the onboard 
1 5 computing device. Accordingly, the method provides, in one embodiment, for a storage of 
vehicular events in a register or other temporary storage module, the events bemg 
specified in the diagnostic information base. 

The managed object, for example, may be ENGINE TEMPERATURE, and the conditions 
20 for that managed object may be a MAXIMUM THRESHOLD, CURRENT VALUE, and a 
TIME COUNT for recording when the current value is to be measured. 

An example of a diagnostic information base is shown in the following table: 



TABLE 1 



MANAGED 


VALUE 1 


VALUE 2 


VALUE 3 


VALUE 4 


OBJECT 
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TE: ENGINE 
TEMPERATURE 


THRESHOLD 


CURRENT 
VALUE 


MEASURE 

EVERY 
lOMINUTES 




T02: 02 
SENSOR 


THRESHOLD 


CURRENT 
VALUE 


MEASURE 

EVERY 30 
MINUTES 





An example of an event recording register is shown in the following table showing the 
current values for the managed objects at a particular time T = Tl 



TABLE 2 







Xn 










Yti 







5 



In one example, the INFORM protocol data unit is sent as a result of a regulatory 
threshold level being exceeded. 

Preferably, the method includes the step of enabling the vehicular onboard computuig 
10 device to wait for a confirmation that a previous INFORM protocol data unit has been 
logged in a data base by the remote monitoring recipient In this case, the method 
preferably also includes the step of re-transmitting the INFORM protocol data unit in the 
absence of a confirmation that a previous INFORM.protocol data unit has been logged in a 
database by the remote monitoring recipient. 

15 

Preferably, the method includes the step of enabling the remote monitoring recipient to 
issue a SET protocol data unit to the vehicle on-board computing device to set one or more 
of the managed objects. 

8 
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The wireless data link may be a radio frequency band under the lEEB 802.1 1 standard, a 
satellite RF packet network or a terrestrial RF packet networic, or otiiers. 

S In one embodiment, the protocol data unit is a '"request* '-type (GET, SET or INFOR^!0 
protocol data unit, the protocol data unit excludmg tiie ERROR STATUS and m(ROR 
INDEX fields of the SNMP protocol. 

In one mibodiment, the protocol data unit excludes the LENGTH field of each variable 
10 bindmg of the SNMP protocol 

In still another of its aspects, the present invention provides a method of conveying vehicle 
operation data from a vehicle to a remote monitoring recipient, comprising the steps of: 

IS - establishing a data link between the vehicle and the remote monitoring 

recipient; 

" collecting vehicle operation data from data sources in the vehicle; 

20 - packaging the vehicle operation data in a data packet using protocol derived 

' from SNMP; and 

- conveying the data packet over the data link, tiie protocol data unit being issued 
in response to a request by the remote monitoring recipient and containing both 

25 the request and requested values in the request and being encapsulated witiiin a 

single message and in a single unfragmented network packet 

In still another of its aspects, the present mvention provides a method of coUectmg vehicle 
operation data from a vehicle for later transmission to a remote monitoring recipient in a 
30 manner to minimize the bandwidth requirements for the later transmission, comprisii^ the 
steps of: 

- providing a vehicle on-board computing device; 

9 
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- providing a number of data acquisition modules, each to record a current value 
of a managed object of the vehicle; 

5 - interfacing the vehicle on-board computing device with each of the data 

acquisition modules; 

- configuring the vehicle on-board computing device to: 

10 a) form a diagnostic information base for receiving and storing values of 

the managed objects from each of the data acquisition modules; 

b) assemble an event report based on information contained in the 
diagnostic information base; and 

15 

c) package the event report into a protocol data unit, the protocol data unit 
includmg a protocol data unit payload having a plurality of VARIABLE 
BINDING fields, each VARIABLE BINDING field having an OBJECT 
IDENTEFIBR field of two bytes, a VALUE TYPE field of one byte and a 

20 » VARIABLE BINDING value of a size according to the VALUE TYPE 

field. 

In one embodiment, the protocol data unit includes a header having a PDU TYPE data 
element with a value corresponding to one of a set of values, the set including a GET 
25 value, a SET value, a TRAP value, an INFORM value and a RESPONSE value. 

In still another of its aspects, the present invention provides a computer implemented 
system for conveying vehicle operation data firom a vehicle to a remote inonitoring 
recipient, comprising: 

30 

- a vehicle on-board computuig device in communication with a number of 
vehicle operation data soiirces in the vehicle; 
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" a wireless communications device for establishing a ^reless data link with the 
vehicle on-board computing device and the remote monitoring recipient 

- the vehicle on-board computing device being enabled to package the vehicle 
operation data in a data packet using protocol derived from SNMP for 
transmission to the remote monitoring recipient over the wireless data link* 

In still another of its aspects, the present invention provides a computer-^readable data 
structure for collecting and conveying vdhicle operation data from a vdiicle to a 
remote monitoring recipient, comprising: 

- an application module for receiving vehicle operation data from a number of 
data sources in the vehicle; 

- a storage module for storing a diagnostic information base, the diagnostic 
information base including a number of managed objects for a number of 
vehicle operation parameters and a number of values for each of the managed 
objects; and 

- a communication module for conveying protocol data units under a protocol 
' derived from SNMP over a wireless data link to the remote monitoring 

recipient 

In still another of its aspects, the present invention provides a computer program product 
encoded in a computer readable medium including a plurality of computer executable 
steps for a computer on-board a vehicle for collecting and conveying vehicle operation 
data from the vehicle to a remote monitoring recipient, comprising: 

- receiving vehicle operation data from a number of data sources in the vehicle; 

- storing, in a diagnostic information base, a plurality of managed objects for 
each of a number of vehicle operation parameters; 

11 
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- establishing a wireless data link between the computer and the remote 
monitoring recipient. 

- conveying a number of protocol data units under a protocol derived from 
5 SNMP over a wireless data link to the remote monitoring recipient 

In still another of its aspects, the present invention provides a signal propagated on a 
• carrier medium, the signal including a packaged protocol data unit containing a payload 
encoding predetermined operational data of an automotive vehicle, according to a protocol 
10 derived from SNMP. 

Preferably, the payload includes a plurality of VARIABLE BINDING fields, each 
VARIABLE BINDING field having an OBJECT IDENTIFIER field of two bytes, a 
VALUE TYPE field of one byte and a VARIABLE BINDING value of a size according to 
15 the VALUE TYPE field data unit. 

Preferably, the payload includes a GPS position segment, a GPS hejading segment, a 
vehicle speed segment or an OBDII vehicle emissions segment. 

20 In still another of its aspects, the present invention provides a system for conveying 
vehicle operation data from a vehicle to a remote monitoring recipient, comprising: 

- vehicle on-board computing means in communication with a number of vehicle 
operation data source means in the vehicle; 

25 

- wireless commimications means for establishing a wireless data link with the 
vehicle on-board computing means and the remote monitoring recipient; 

- the vehicle on-board computmg means being enabled to package the vehicle 
30 operation data in a data packet using protocol derived from SNMP for 

transmission to the remote monitoring recipient over the wireless data Imk. 

In still another of its aspects, the present invention provides a method of conveying vehicle 

12 
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10 



Operation data from a vehicle to a remote monitoring recipient^ comprising: 

- a step for establishing a data link between the vehicle and the remote 
monitoring recipient; 

- a step for collecting velucle operation data from data sources in the vehicle; 

- a step for packaging the vehicle operation data in a data packet using protocol 
derived from SNMP; and 

- a step for conveying the data packet over the data link. 



In yet another of its aspects, there is provided a computer-readable data structure for 
collecting and conveying vehicle operation data from a vehicle to a remote monitoring 
15 recipient, comprising: 

- an application module for receiving vehicle operation data from a number of 
data sources in the vehicle; 

20 - a storage module for storing a diagnostic information base, the diagnostic 

information base including a number of managed objects for a number of 
vehicle operation parameters and a numb^ of values for each of the managed 
objects; and 

25 . - a communication module for conveying protocol data units under a protocol 
derived from SNMP over a wireless data link to the remote monitoring 
recipient 

In still another of its aspects, the present invention provides a conmiunications network for 

30 exchanging data between a plurality of vehicles, comprising a computing unit onboard a 

corresponding vehicle, wherein the computmg unit in a given vehicle is operable to 

broadcast identity messages and to receive equivalent identity messages from otiier 

vehicles in an adjacent region, where said messages are used to identify the neighbouring 

13 
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vehicles in the network for exchanges data with selected ones of the vehicles^therein. 

Preferably, the computmg unit is opeiable to update a list of neighbouring vehicles. In this 
case, the computing unit may add new neighbour vehicles to the list as identity messages 
5 are received firom new vehicles entering I3xc region. Alternatively, the computing unit may 
delete a given neighbour vehicle from the list ^en identity messages are not received 
firom the given neighbour vehicle after a predetennined period of time. Alternatively, the 
computing unit deletes a given neighbour vehicle vehicles firom the neighbour database 
when the lack of identity messages received firom the given neighbour vehicle indicate that 
1 0 the neighbour vehicle has left the adjacent region. 

Preferably, the medium of conmiunications is a high firequency channeli2;ed RF band and 
its use by each of said computing units is controlled according to the IEEE 802.11 
Medium Access Control (MAC) protocol. 

15 

Preferably, the computing units are Internet addressable. 

Preferably, the computing units are IPv6 addressable. 

20 . Preferably, the computing units exchange data using an SNMP-derived protocol. 

Desirably, the identity messages mclude GPS information and tiie IEEE 802.11 MAC 
address of the sender, wherein the GPS mformation mcludes latitude, longitude, speed and 
heading information. 

25 

In one embodhnent, all vehicles in the neighborhood broadcast theur identity messages 
over a discovery time period that is sufBdent to allow any given vehicle to recognize all 
its neighbours. Both the length of the discovery period and the geographic si2:e of the 
region may be adjusted in proportion to the average speed of tiie vehicles in the 
30 neighborhood. 

If desured, the channel selection for transmission of at least some messages nmy be based 
on GPS heading. 

14 
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In one embodiment, each of the computing units further comprises a transmitter and 
receiver capable of transmitting and receiving messages under an SNN4P protocol 

S In another of its aspects, the present invention provides an automotive vehicle as above* 

* • * 

In still another of its aspects, the present invention provides a data structure comprising a 

speed segment, a heading segment and position segment Preferably, the position segment 

includes a longitude portion and a latitude portion. 

10 

In another of its aspects, the present invention provides a signal propagated on a carder 
medium, the signal including a speed segment, a heading segment and a position segment 
Preferably, the position segment mcludes a longitude portion and a latitude portion. 

15 In still another of its aspects, the present invention provides a vehicle comprising an 
onboard computing unit operable to receive messages from other vehicles in an adjacent 
region for assembling a neighbourhood list for exchanging data with selected ones of the 
vehicles listed therein. 

20 In yet another of its aspects, the present invention provides computer program product for 
operating a programmable computer system on board a motor vehicle, comprising a 
computer readable medium including the computer executable steps of receiving messages 
from other vehicles in an adjacent region and of assembling a neighbouriiood list for 
exchanging data with selected ones of the vehicles listed therein. 

25 

In yet another of its aspects, the present invention provides a motor vehicle comprising an 
onboard general purpose computer and a:spread spectrum radio, the spread spectrum radio 
operable to establish a data link widi a radio m at least one other neighbouring vehicle, 
wherem the computer is operable to record messages firom at least one other vehicle in an 
30 adjacent region for assembling a neighbourhood list, and to identify at least one vehicular * 
event from data received on the data link. 

In yet another of its objects, the present invention provides a computer-readable data 

IS 
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Structure for collecting and conveying vehicle operation data from a vehicle on-board 
computmg device and a remote monitoring recipient, comprising: 

- a module for hidexing a series of protocol values and corresponding requests 
5 . and responses for data exchange between the vehicle on-board computing 

device and the remote monitoring recipient; 

- a module for indexing a series of mana^d objects, for a mmiber of operating 
characteristics of the vehicle; and 

- a module for recording values for each of the managed objects. 

10 Preferably, the data structure further comprises a module for indexing an identity for each 
remote monitoring recipient 

Preferably, the data structure also includes a module for indexing a list of one or more 
authorization levels for each remote monitoring recipient. These authorization levels may 
be used to impose conditions on the managed object values being conveyed to the 
15 recipient Some recipients may be entitled to all of the managed object values, others to 
' only some of the them, and still other requesting entities (those not in the list) entitled to 
none at all. 

BRIEF DESCRIPTION OF THE DRAWINGS 

20 

Several preferred embodiments of the present invention will be provided, by way 
of example only; with reference to the appended drawing, wherein: 

Figure 1 is a schematic view of a protocol stack; 

25 

Figure 2 is a schematic view of a UDP based protocol; 

Figure 3 is a schematic view of a TCP based protocol; 

30 Figure 4 is a schematic view of a header in a UDP based protocol; 

16 
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Figures S(a) and (b) are perspective schematic views of two network arrangements; 

Figure 6 is a schematic view of an SNMP protocol data unit; 
5 Figure 7 is a schematic sequential view of a data gram exchange; 
Figure 8 is a schematic view of a GET protocol data unit example; 

Figure 9 is a schematic view of an MIB hierarchy for SNMP; 

1 0 Figure 1 0 is a schematic view of a portion of a DIB liierarchy ; 

Figure 1 1 is a schematic view of a message sequence; 

Figure 1 2 is a schematic view of a network; 

15 

Figiue 1 3 is a schematic view of a protocol stack for exchangmg data using the network of 
figure 12; 

Figure 1 4 is a schematic view of another networic; 

20 

Figure 1 S is a time plot of beacon frame sequence; 
Figure 16a is a schematic view of a portion of an adhoc network; 
25 Figure 1 6b is a time plot of beacon frames issued by vehicles in network of figure 1 6a; 
Figure 1 7 is a schematic view of another adhoc network 
Figure 1 8 is a sdiematic view of another protocol stadc;; 

30 

Figure 1 9 is a schematic view of another protocol data unit; 
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Figure 20 is a schematic view of a quadrant divided highway segment; 

Figure 21 is a schematic wicw of a data exchange during a driving manoeuvre; and 

5- 

Figure 22 is a schematic view of data exchange during another driving manoeuvre. 

DESCRIPTION OF THE PREFERRED EMBODIMENTS 

10 Described herem below is a system and method which implements a peer-to-peer Intemet- 
basediprotocol stack for vehicular diagnostic telemetry. This stack is mtended to reside in 
on-board vehicular embedded systems and to enable remote PC workstations to interact 
with these systems using standard communications API's such as Winsock. 

The Session and Presentation layers of the stack are labeled the Automotive Telemetry 
15 I^tocol (ATP). ATP addresses flie need for a clear specification of the message formats, 
protocol procedures, security mechanisms and external inter&ces by which software can 
be developed for implementation of OBD-III* on different mobile and fixed computing 
platforms in an inter-operable £ashion. 

Reviewed below are the objectives sought and then provides a more detailed description of 
20 the layers 3-6 (network, transport, session and presentation). It has been shown that the 
Session and Presentation layers are derived from the specifications for Simple Network 
Management Protocol (SNMP), The underlying transport mechanism is a UDP/DP stack 
with Ae UDP header compressed in the mterest of bandwidth efficiency. 

The issue , of security is also addressed below, and the ability to configure an 
25 implementation of the stack such that specific sources of data can be restricted to specific 
requesting entities ("clients"). The application of flie Secure Socket Layer. (SSL) protocol 
is reviewed in order to demonstrate the authentication of requests for information fix>m 
extCTial sources by the on-boaid computer. 



' On-Board Diagnostics m. Proposed legislation, spearheaded by Califomia Air Resources Board 
(CARB) requiring emissions-related diagnostic information fi-om Engine Control Modules (ECM's) in 
vehicles to lend itself to retrieval over mobile communications networks. 
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The protocol stack is applied to the exchange of operational data between vehicles on the 
road. This is based on the concept of an "ad-hoc network" established within a 
"neighborhood" surrounding any given vehicle. The ad-hoc network can co*exist with a 
data link to the Internet, using the same RF mecfium, provided that a roadside 
5 infrastructure is deployed The potential of this technology to improve highway safety is 
illustrated with various examples of vehicle-to-vehicle exchange of operational 
information. 

Also described a method for the integration of IEEE 802, 11 compliant technology in both 
intelligent vehicle and intelligent highway systems. Reference will be made herein below 
10 to hitelligent Transportation Systems or ITS to encompass any component of such 
systems, whether on board a velldcle or part of the roadway infrastructure. 

Much of the current focus of intelligent vehicle technology is directed at collision 
avoidance based on radar. On the other hand, intelligent highway system development has 
1 S been largely predicated on the use of short-range communications between the vehicle and 
the roadway infiastnicture. However experts fiom both the automotive OEM*s as well as 
from government agencies have recogmzed that vehicle-to-vehicle communications 
constitutes an area that should be explored going forward. . 

20 The IEEE 802,11 specification is a relatively new standard for high-speed wireless Local 
Area Networks (LAN). It uses a method of RF transmission known as spread spectrum 
. for which the 2.4 GHz range has been made available as an unlicensed band. This 
technology is also identified under the commercial banner Wi-Fi (Wireless Fidelity). Its 
potential for application in the area of ITS is based on its commercial potential. There are 

25 now Wi-Fi products commercially available that make it possible to create network 
infrastructures supporting mobility for computer devices. Network interface cards (NIC*s) 
are available enabling personal computers, including laptops and notebooks, to use Wi-Fi. 
As the popularity of Wi-Fi grows, it is expected that more mobile wireless appliances (e.g. 
PDA's, cell phones) will appear in the marke^lace that exploit a growing infrastructure of 

30 access points through which users can connect to the Internet wirelessly at bit transfer 
rates that currently reach 1 1 Mbps. 

19 

-SUBSTITUTE SHEET (RULE 26) 



wo 02/31793 



PCT/CAOl/01420 



One feature of IEEE 802.11 is the notion of ad hoc networking, which enables two or 
more devices to communicate directly with one another without requiring a fixed access 
point In other words, the network infrastructure is not a necessary condition for 
connectivity between mobile devices. As a result, IEEE 802.11 can support concurrent 
5 vehicle-to-vehicle and vehicle-to-infrastructure communications in novel and unexpected 
ways. This combination of flexibility, from a technical perspective, and commercial 
appeal, is the essential rationale for using IEEE 802.1 1 in ITS. 

The method described in this document adheres to the principle of implementing fully- 
10 compliant 802.11 nodes, without modification of the specification, to meet the 
requirements of ad hoc networlcing for ITS. 

RdationshiptoATP 

15. The methods described here are intended to provide a platform on which the Automotive 
Telemetry Protocol (ATP) can operate between two vehicles. ATP is a session level 
protocol derived from SNMP that enables a bi-directional client-server relationship to be 
established between the two end points of the mobile communications [1]. In the context 
of vehicle-to-vehicle communications, ATP allows a "client" vehicle to send an 

20 asynchronous notification to specified "server" vehicle requiring acknowledgement This 
request-response mechanism has applications described later in this document 

PROTOCOL STACK 

Figure 1 illustrates the complete protocol stack that is required for OBD ni, usuig the OSI 
2S (Open Systems Interconnect) reference model 

The protocol stack is intended to meet one of more of the following objectives: 

• Wireless data link transparency 

This refers to the need for technology-independence. It should be possible for OBD-III 
compliance to be met using a variety of wireless data link technologies. Mobile devices 
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should be able to use packet cellular, RF packet networks, wireless LAN (Wi-Fi), satellite 
or any combination thereof. 

• Internet connectivity (bqrond OEM portals) 

It should be possible for worlcstations at remote IP addresses to interact directly with an 
5 on-board vehicular device that interfaces to OBD and other operational data within the 
vehicle. In other words, full Internet connectivity between the vehicle and any remote 
host is a desired outcome that will enable authorized hosts to run applications that do not 
have to transit the OEM's portals. This implies that the vehicular device needs to comply 
with standard protocol specifications that support peer-to-peer exchanges with any 
10 authorized host on the Internet (See Security below in relation to the- notion of 
authorized has f). 

• Efficient bandwidth utilization 

The data exchange between fixed sites, responsible for monitoring, and the mobile units 
should not be unnecessarily "verbose". There is a tendency in wreless applications to 

15 assume that some form of "Web" presentation is required to simplify the us^ interfece 
(UI), which has been partly respon^ble for the development of Wireless Application 
Protocol (WAP). WAP is a technique that offers SOTie compromise between the UI 
features of the Web and the need for bandwidtti efEtciency over airlinks. None of these 
considerations take into account the &ct that telemetry traffic is quite different in its 

20 . purpose than other forms of wireless data and should be supported m a different, yet 
standards-based manner. 

• Standardized data exchange mechanism 

The higher levels (Session and Presentation) of fhe protocol stack need to be standardized, 
for obvious reasons. This will* sinq)lify the task of compliance with OBD-m in all 
25 jurisdictions that choose to implement the regulations. 

• Security 

The need for security has been stressed by CARB. Political acceptance of the OBD-III 
concqpt is depmdent on the public's confidence that the technology will not become a 
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fonn of state intrusion into individual .privacy. Motorists and vehicle owners should have 
the perception that electronic controls over the release of information are at least as 
effective as those that are currently in use in Web*based B'<x>nunerce. It is contemplated 
that the present system will, if needed, be capable of implenienting public key 
5 cryptography above the Session layer, in much the same manner that it is done in 
• busmess-to-consumer E-commerce. This ensures that, although there is connectivity with 
any host on the Internet, only those hosts that obtam authorization through the security 
mechanisms will receive any '^attention" from the vehicle. 

Network and Transport Lavers UDP/IP - In order to understand the context in which ATP 
10 operates, the underlying transport mechanism which supports it's needs to be considered 
The User Datagram PFotocol(UDP) is a transport-level mechanism for "connectionless" 
client-server communications. UDP constitutes one of the transport protocols that can 
operate over the Intemet. The notion of a ''connectionless" protocol refers to the fact that 
there is no overhead dedicated to the maintenance of reliable end-to-end communications. 
15 In diis sense, UDP is distinguished from TCP (Transport Control Protocol). The shorter 
UDP header (8 bytes) reflects this difference. 

The basic protocol data unit (PDU) of the Internet is called a datagram. The datagram 
header contains a field that is used to designate the protocol at the next level of the stack. 
The lANA^ f values for UDP and TCP are, respectively, 17 and 6. The figures below 
20 show how the payload of different datagrams can be intended for UDP and TCP, 
depending on the value of the "protocol" field in the datagram header. 

As mentioned above^ the standard UDP header is eight (8) bytes in length, consisting of: 

• source port (2 bytes) 

• destination port (2 bytes) 
25 • payload length (2 bytes) 

• checksum (2 bytes) 



^ lANA (Internet Assigned Numbers Authority) 
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In the conventional uses of UDP, the source and destination ports are lANA-approved 
numbers associated with processes executing withm the sender's and the receiver's address 
spaces, respectively. There is currently no assigned number for the present automotive 
telemetry application. The present system uses the number 0x0 A (integer 10) to specify 
5 the ATP port? 

Compression of the UP? Header - In the application of automotive telemetry, the 
overhead of the UDP header would consume wireless bandwidth without, providing any 
significant advantage to the protocol in terms of flexibility or reliability. Both the source 
and destination ports can be constrained to use the same number. The payload length can 
10 be derived from fields in the und^lying network packet or data link fi:ame in which the 
UDP segment is encapsulated. Finally, the checksum can be viewed as redundant, since 
the underlymg data Imk protocol(s) should incorporate an integrity check of the data 
stream anyway* ^ 

Given the need to minimize wireless bandwidth consumption, the UDP header is , in one 
IS embodiment, reduced to 1 byte in the implementation herein of the mobile 
communications protocol stack, which is illustrated in Figure 4. The value in tliis byte 
(OxOA or integer 1 0) identifies the ATP port at both the source and destmatioa 

Session and Presentation Layers - A TP resides conceptually at the Session Layer. It is a 
request/response mechanism, similar to Simple Network Management Protocol (SNMP), 
20 which ensures that for every message fi-om either a mobile xmit to the base location or vice 
versa, there is always an acknowledgement. As such, exception reports from vehicles 
cannot be discarded by the mobile computing platform until the base system has 
confirmed that they have been logged to a "persistent storage" database. 

The design philosophy of ATP is based on Simple Network Management Protocol 
25 (SNMP) which enables remote diagnostics and configuration of commxmications devices 
and is the de-facto standard with which elements of the Internet infrastructure must 



^ This number is» as yet, unassigned by lANA. 

^ If any of the data links traversed from source to destination do not incorporate integri^ checks in Ae 
protocol, Aen the data integrity of ATP can be called into question. However, it is difiBcult to envision such 
a'case. 
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comply. A comparison can be made between remote diagnostics of communications 
devices and mobile vehicles. This is illustrated graphically in Figures 5(a) and (b). 

In SNMP tiie "managed entlQ^* is typically a conMminication switchii^ device such as a 
bridge or router. This managed entity inqplements an "agent", which is a software module 
5 re^nsible for retrieving requested information and interacting with the remote 
"manager" through an interface to the communications, protocol stack. Figure 5(a) shows 
that the top level of this stack is SNMP, which is essentially a combmation of the Session 
and Presentation Layers. The information that a remote manager may request resides m 
the Management Information Base (MIB), which is a local repository for operational data 
. 10 collected by the device drivers controllmg Hic hardware interfaces tp the external world 
("Communicatioxis Modules"). For instance, a router with an Ethernet adapter maintains 
statistics reporting the number of inbound and outbound frames transiting the Ethernet 
mter&ce. This information is cached in the MIB and is retrieved by the Agent on behalf 
of a remote Manager which has issued a request. 

15 • In the case of ATP, shown in Figure 5(b) below, flie entity equivalent to the SNMP 
Manager is called a Monitor^ and the managed entity is a vehicular on-board computing 
device interfaced to various data acquisition modules^. This is called the local data 
repository a Diagnostic Information Base (DIB), The information cached in the DIB 
originates from various sources such as the ECU diagnostic port, analog and digital 

20 sensors, GPS receiver, and so on. The three examples shown in the figure are: 

•. SAE J-1979 (diagnostic test modes requured for OBD-II) 

• GPS receiver 

• direct analog and digital input chaimels 

This is by no means an exhaustive list of the possible sources of data* Other examples are: 
25 ' • SAE J-21 90 (reconmiended supplement to le^slation) 

• SAE J-2I78 (Normal Vehicle Operation) 



The present version of such a device is called a Universal On-Board Diagnosdc Server (U^OBD). 

24 

SUBSTITUTE SHEET (RULE 26) 



wo 02/31793 



PCT/CAOl/01420 



• SAE J-1708 (heavy truck and bus) 

• SAE J-1939 (successor to M708) 

SNMP and ATP Message Formats - The SNMP message consists of a header^ and a 
Protocol Data Unit (PDU). The header contains two fields: 

5 • Version Number 

This specifies the version of SNMP that is bemg used by the originator of the message, 

• Community Name 

This serves as a primitive method of authentication^ Managers belonging to a community 
are said to exist within the same administrative domain. When a management agent 
10 receives an SNMP message from a manager containing a community name that it does not 
recognize, it does not participate in the SNMP operation. 

In the present sj^m, it is preferable to eliminate fields that are potentially redundant in 
order to reduce the consumption of wireless bandwidth* This is the case with the 
community name since, as will be shown, a much stronger form of authentication is 
15 requked at the presmtation level (i.e. the layer above ATP). A version number will only 
become necessary once ATP evolves beyond the experimental stage, 

SNMP Protocol Operations - The rest of the SNMP message is the Protocol Data Unit 
(PDU), There are four (4) basic types of request PDU defined in the SNMP specification 

[If: 
20 • Get 

Amanageruses a Get PDU to retrieve an itoB from an agent's MIB 



^ The present version of such a device is called a Universal On-Board Diagnostic Server (U-OBD). 
* Tins describes the message header format of the initial version of SNMP, SNMPv3 specifies a more 
complex format This will become useful as a reference point when security mechanism is specified for 
ATP. 

' The document in reference [I] is the most recent RFC (Request for Comment) for the initial version of 
SNMP. The full complement of specifications for SNMP also includes a set of RFCs for SNMPv2, which 
extends the functionalitj; of SNMP, and a set of RFCs for SNMPv3, which provides security features. The 
term "SNMP specifications" is used in this document to refer to the full complement of specifications 
provided in the RFCs published by the Internet Engineering Task Force (IETF). 
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• Set 

A Set PDU is used by a manager to set a value in an agent's MIB* 

• Trap 

An agent uses a TYap PDU to send asynchronous notifications or "alerts" to a manager. 
S The manager does not acknowledge these notifications. 

• Inform 

An Inform PDU is sunilar to a Trtp PDU. Any SNMP entity (either an agent or a manager 
communicating with another manager) may use an Inform PDU to send asynchronous 
notifications. In contrast to a Trap PDU» the receiving manager must acknowledge an 
10 Inform m\J. 

Pmtocol Data Unit Formats - These four categories* of PDU are highly suited to ATP. 
Before their use is examined in the context of automotive telemetry, the actual format 
specification for the SNMP PDU's will be summarized. Figure 6 illustrates the format for 
Gfi/, Set and Response PDU's: 

15 • PDU Type 

This specifies the type of PDU. This is either one of the four request PDU types ahready 
described or a response. 

• RequestID ' 

This is essentially a sequence number for the PDU. The receiver of a request PDU uses 
20 this m the response PDU so that the sender can match the response with a previously 
transmitted request It also ensures that the receiver can filter out duplicate messages. This 
is particularly important in mobile wireless networking environments, where transient 
conditions render mobile nodes fi:equently "umeachable", which causes the sender to 
attempt retries. In this kind of scenario, the probability of duplicate messages arriving at 
2S the destination is very high. 

' The typos of request PDU previously described are categories, within which several sub-types are defined 
by later versions of SNMP, 
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This is shown in figure 7. A request PDU, encapsulated in a datagram, is routed to a 
• mobile agent through a gateway to a mobile network. It is then wrapped in a mobile 
network packet and routed to the mobile agent through a wireless link from the closest RF 
base station. Whereas the mobile agent may receive the airlink frame containing the 
5 packet, the RF base station may not "hear" the acknowledgement that is transmitted in 
response. After the requisite timeout period, the RF base reports back to the mobile 
network gateway that the mobile agent is "unreachable". When this report is propagated 
back to the sender (ATP monitor), the message is re-transmitted. 

• Error Status 

1 0 This field is used only in response PDU's. It indicates one of a number of errors and error 
types. 

• Error Index 

This field is used only in response PDU's. It associates the error (if applicable) with one 
of the "variable bindings" encapsulated in the remainder of the PDtJ. 

15 • Variable Bindings 

This is the data field of the SNMP PDU. Each variable binding is an association of a 
particular instance of a managed object, which is part of the MIB, with its current value 
(with the exception of Get request PDlJfs, for which the value is ignored)* The Object 
Identifier (OID) field identifies the object instance. The value of the variable is encoded 
20 accordmg to the triple TLV (type, length, value), where type specifies the data type, length 
is the number of bytes in which the value is represented in the subsequent stream and 
value contams the value in length byte. This encoding scheme follows the practice set out 
in the Basic Encoding Rules (BER) of the Abstract Syntax Notation language (ASN. 1). 

ASN.l is an ISO-specified language that is often used to define data exchange protocols at 
25 the presentation and applications layers of the OSI model. Its abstract quality enables it to 
be independent of the different data representation techniques that can be encountered on 
different computing platforms. Of coiurse, the more abstract the syntax for expressing data 
structure^ the more overhead is requured when these structures are serialized in a data 
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stream over a communications network. For this reason, SNMP uses only a subset of 
ASN.l (specifically a subset of the BER) in order to restrict the overhead associated with 
the encoding scheme and therefore preserving bandwidth on the Intemet. [2], [3] 

In ATP» still wifli the objective of preserving bandwidth (which is all the more important 
5 in the mobile environment of ATP) a further restriction may be imposed on the encoding 
scheme by eliminating the length field for all but variable length strings. This is shown in 
the detailed format of the variable bindmg va the previous illustmtion of the SNMP PDU 
format Only the 0^ field is used. The receiver must infer the length of the va/i/e field 
from the received type. 

10 This same format has been adopted, in one embodiment, as a model for the ATP PDU's, 
However, in order to limit unnecessary use of bandwidth in the wireless environment, the 
following exceptions are made: 

1 . The EfTor Status and Error Index fields are not present in the request PDlPs. 

2* The value fields for the variable bindings are not present in Get PDU's. 

15 3. The lengths of all fields in the PDU's, including the ODD and value fields in the variable 
bindings (excluding character strings), .are implicit; i,e* they are not explicitly encoded in 
the data stream *as specified by ASN, 1 . The lengths of all the header fields are restricted to 
one byte. The length of OID fields is two bytes and the lengths of the variable binding 
values are dependent on the value type, which is encoded in one byte. 

20 ATP Protocol ODerations with the SNMP PDU's - As ahready stated, the SNMP PDlTs, 
with the modifications described in the pre\dous section, are applicable to the protocol 
requirements of AIT. Get PDU's are needed when an ATP Monitor wants to retrieve the 
current values for a specific set of managed objects firom a vehicle. An example is 
illustrated in the figure 8. A vehicle owner could obtain, firom a fixed-location 

25 workstation, the vehicle's GPS location, engine speed, road speed and engine tempemture. 
Both tile request for all of this data and the response fiom the vehicle containing all the 
requested values would be encapsulated withm a single ATP message and a unfiagmented 
network packet. 
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The Trap PDU can be used to send event reports fix)m the vehicle for which 
acknowledgments are not required. A typical example would be a recurring GPS 
position report Application software in the on-board device^ could generate a 

Trap PDU with the GPS position at an interval specified within the data structure for the 
5 GPS "managed object". The purpose of this reporting would be to track a vehicle in real- 
time* Therefore acknowledgements ficom the Monitor are superfluous since the sender has 
no reason to re-transmit GPS positions that become immediately stale. 

The Inform PDU, which requires acknowledgements, is the mechanism that is used more 
commonly in ATP to send a synchronous event report from the vehicle. These events can 
10 correspond to: 

• Regulatory exceptions (e.g. emissions-related events requiring intervention) 

• Maintenance exceptions (e.g.&ult conditions requiring immediate 
inspection/validation/repair) 

• Operational exceptions (e.g. use of the vehicle in an unauthorized manner) 

IS Since an acknowledgement is required for this PDU, the on-boaid monitoring agent has a 
means of determinmg w^iether the event report has been logged m a database.^^ 

The Set PDU is used to remotely change the operating parameters of the on-board device. 
This could be, for instance, the threshold level at which a regulatory exception occurs or 
the interval of unsolicited GPS position reports (for a tracking application with Trap 
20 PDUs). 

MIB Hierarchy and DIB Derivation - The MIB to which SNMP provides access is a 
collection of managed objects which are organized hierarchically, as shown in figure9. A 
managed object is one of any number of specific charact^istics of a managed device. 



^ The SNMP specifications for agent software architecture call this the Notification Originator 
Application. The peer software in the manager entity is called the Notification Receiver Application. 

It is the re^nsibiiity of the Notification Receiver Application to ensure that these reports are committed 
to a database before the acknowledgement PDU is returned to the agent 

The terms MIB object^ object^ or simply MIB, are used hiterchangeably with the term managed object. 
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Managed objects are comprised of one or more object instances^ whidi ate essentially 
variables. 

Figure 9 illustrates the MIB hierarchy as a tree, the levels of which are assigned by 
different organizations. An object identifier (OLD) uniquely identifies a managed object in 
5 this hierarchy. The top-level OID's belong to different standards organizations, while 
lower-level OID's are allocated by associated organizations. The OID is formed firom the 
sequence of numbers corresponding to the nodes through which a managed object can be 
reached from the root of the tree. For example, the sequence: 

13 6 12 

10 identifies the MIB-2 object, which is the MIB for entities that comply wi& the 
specifications of the TCP/IP protocol stack. The full object name is: 

iso.identified-organization.dod.intemet.mgmtmib-2 

Suppose that this MIB is maintained on a remote router with interfaces to several 
networks. The objects representing these interfaces are maintained in a table, each of 
15 whose entries is a collection of variables associated with network interfaces. Suppose, for 
instance, that af\ SNMP manager wanted to retrieve the number of octets received (since 
the last start-up) on the first network interface. The OID iderUifying this object would be: 

1 3 6 1 2 1 2 1 10 

and the object name would be 

20 iso«identified-orgaiiization.dod.internet.mgmt.mib-2JnterfacesifUbleifent^^ 

A similar arrangement is contemplated for the hierarchy of the Diagnostic Information 
Base. The question that arises is wheth^ a DIB sub-tree should branch out from the 
Intemet node or whetiief an SAE sub-tree should branch out from the Identified 
Organization, It is evident that these two options would appear as shown m Figure 10. 
25 The illustmtion makes the root of the new sub-tree should be the DIB nodQ. Furthermore, 
smce ATP is a (proposed) protocol which operates at the same level as SNMP within the 
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Internet suite of protocx>ls, it is also clear that the DIB should exist with the sub-tree 
startmg at the Internet node. 

It is not evident how the DIB could exist within a sub-tree with Its root at the SAE node, 
without a duplication of the Internet node. This would be a violation of the rule that any 
5 node on the hierarchy can be uniquely identified. Therefore, it would appear to be more 
logical that the new sub-tree originates at the ATP node. 

As .mentioned previously, the OID*s in the variable bindii^ of ATP PDLTs are encoded in 
a fixed length of two bytes. This means that the entire parent hierarchy of the object is not 
mcluded to which the OID refers. The prefix 

10 1 3 6 1 2 8 

corresponding to the object name 

iso.identified-organization.dod.intemetmgmt.dib 

is an implicit part of each OID. Only the portion below the DIB node is serialized and 
transmitted over the network 

15 User Configuration - At the highest level of the protocol stack, there can be some form of 
user interface allowing the installer (or eventually the driver) to specify which sources of 
internal vehicular data should be accessible to which remote ^'clients". The next section 
explams how the identity of any remote client can be completely authenticated and how 
the subsequent data exchange between client and (vehicular) server can be made secure 

20 against any eavesdroppers. 

Security - With ATP, the agent should have the authority to accept or reject requests fcom. 
the monitor, based on the nature of the request and the identity of the monitor. For 
instance, a request firom a remote monitor to report the current GPS location may be 
considered an invasion of privacy if it originates fi'om a location not controlled by the 
25 vehicle owner. Similarly, a request for OBD information (SAE J-1979) could also be 
rejected, unless it originates firom the 3[nonitor(s) authorized, according to the User 
Configuration* 
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In order to meet these requirements, the communications linJk between the mobile agent 
and the monitor must provide both for privacy and authentication of the requesting entity; 
i.e. the monitor. An ideal ftamework for this is the Secure Socket Layer (SSL) protocoh 
SSL was developed by Netscape and has become the de-facto standard for inter-operable 
5 security between clients and servers in the Internet and particularly for Web-based E- 
conamerce^^ SSL defines a handshaking protocol allowing for authentication of either 
party by the other usmg public-key encryption methods which are effectively unbreakable. 

Normally, SSL operates on top of TCP/IP, which constitutes the underlying transport 
mechanism for Web trafQc, However, because of the nature of the tel^etiy application, 
10 • ATP uses the UDP/IP stack. The lower edge of the SSL record layer must therefore be 
adapted to inter&ce to the UDP transport mechanism* 

Figure 11 shows the security mechanism of SSL introduced between the ATP layer and 
the presentation layer, where the Protocol Data Unit (PDU) is parsed into individual 
requests for specific sources of data. The security layer acts as an effective "firewall" 
IS against unauthorized intruders. It authenticates the remote monitor and maintains privacy 
for the contents of the subsequent PDU's that are exchanged across the session. The 
interface between the SSL handshaking protocol and the presentation layer should provide 
a mechanism for SSL to precede the annoimcement of a received PDU with an 
identification of an authenticated monitor requesting information. 

20 This mechanism, as well as the subsequent data exchange, is illustrated by the sequence in 
Figure 11. 

The individual steps of this sequence can be described as follows: 

1 . The Monitor's presentation layer notifies its security layer that it wants to issue a request 
to the Mobile Agent 

25 The SSL Handshaking must now take place between client (Monitor) and server (Mobile 
Agent). 



See the specification in [4]. 
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2. The SSL handshake layer asks the SSL Record Layer to enciQ>sulate the requisite 
handshake message. 

3, The SSL Record Layer sends an asymmetrically encrypted message (public key 
Glyptography) to the other side. 

5 4. The SSL Record Layer delivers a decrypted message to the SSL Hahdsliake layer 

Steps are repeated m both directions until the authentication of the client has been 
established. 

5. Once the Monitor has been authenticated, SSL reports its identity to the presentation 
layer, so that subsequent requests for information can be accepted or rejected according to 

10 the User Configuration. 

6. The security layer on the Monitor side reports to the presentation layer that the 
authentication has been confirmed. 

7. The Monitor's presentation layer sends the PDU to the security layer tor session privacy 
encryption. The encryption is carried out with a symmetrical one-time key exchanged 

15 between the parties during the SSL handshaking (and which ensures .the privacy of the 
exchange). 

8. The encrypted PDU is '^transmitted'* to the Mobile Agent. In other words, it is passed on 
down through the Session Layer of the Monitor's protocol stack. 

9. When the encrypted PDU arrives at the SSL Record Layer of the Mobile Agent, it is 
20 decrypted before being handed-oflf to the Presentation Layer. 

10. Hie response &om the Presentation Layer is sent to the SSL Record Layer. This 
response may be: 

• data requested by the monitor 

• a confirmation that a command sent by the Monitor has been executed, or 

25 •a rejection of either a command or a request for data because the Monitor does not 

have the requisite authority for the request or command. 
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11. The SSL Record Layer encrypts the response ^th the symmetrical sessidh key ta& 
transmits back to the Monitor (Le. through the protocol stack starting with the Mobile 
Agent's Session Layer. 

12. The Monitor's SSL Record Layer decrypts the PDU and hands it ojff to the Presentation 
5 Layer. 

Note that ail or part of this sequence could be carried out in the reverse direction. Suppose 
that the Monitor represents an emissions control regulatory agency and that a Mobile 
Agent receives a request every year from this Monitor to report all non-compliance events. 
The Mobile Agent may respond with a positive acknowledgement at the presentation 

10 layer, i.e. an acceptance of the request. For the rest of the following 365-day period, all 
exception conditions will cause the Mobile Agent to initiate communications to report 
these conditions. The request will therefore emanate from the Mobile Agent whereas the 
response from the Monitor will indicate that the exception report has been noted and 
logged to permanent storage. (The U-OBD can be configured to keep these exception 

IS reports in Flash memory until an acknowledgement is received from the Monitor. This 
ensures that exceptions that occur while the vehicle is not withm coverage range are not 
"forgotten"). 

VEHICLE-TO-VEHICLE TELEMETRY - Ad Hoc Networking with Wireless LAN's - 
OBD-III is an example of telemetry consisting of a mobile server and a fixed-location 

20 client Also envisioned is the case of a client-server relationship between two mobile 
vehicles. A data link between two vehicles can be established using the ad-hoc 
networking capability of the IEEE 802.11 specification for wireless LAN. Ad-hoc 
networks in wireless LANs are created without a central coordinating node, called an 
access point. Figure 12 illustrates the distinction between an ad-hoc wu:eless LAN and 

25 one with an access point. 

By using different spread spectrum channels, both types of networks can co-exist on the 
same hardware platform. The access point provides the vehicle with connectivity to a 
; Wide Area Network (i.e. the Internet) but is not reqmred for an ad hoc network. The ad 
hoc netsvoric enables vehicles to establish logical links with their neighbors, which can be 
30 used to exchange critical operational information between vehicles. 
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A(l hoc networks can be created using a scheme embodied herein that permits each vehicle 
to maintain a real-time image of its "neighborhood". This neighborhood can include 
vehicles \xp to five hundred yards in both the forward and rear directions. The unage 
maintained within each vehicle changes dynamically with changes in (he surrounding 
S conditions. 

The ATP protocol stack can be used for vehicle-to-vehicle messaging in ahnost the same 
manner as it is used to interact with remote diagnostic cUents. The difference is that 
security restrictions cannot apply m this case since all vehicles must necessarily and freely 
exchai^e information. This is illustmted in Figure 13. 

10 Applications: Safety vs. Congestion Management -Vehicle-to-vehicle communications 
have been used on an experimental basis in the context of "platooning" for Intelligent 
Transport Systems (ITS). Platooning is simply one example of what is referred to herem 
below as "cluster intelligence" on the road. A cluster is the aggregation of vehicles within 
a neighborhood. Since the neighborhood of any vehicle constitutes a fluid network 

IS topology surrounding it, the membership of the associated cluster is dynamic. 

The exchange (or the broadcasting) of information within a cluster has value in terms of 
both road safety as well as traffic management aimed at reducing congestion, hi some 
respects, there is an artificial distinction between these areas. Better traffic management 
should result in better safety and vice versa. The descriptions of the following application 
20 areas do not distinguish between these two purposes. 

Redundancy - Vehicle on-board systems such as cruise control or cockpit electronic 
hxformation systems can benefit Stom a variety of inputs, including forward collision 
avoidance radar as well as vehicle-to-vehicle information exchange fecilitated by ATP 
with ad hoc networking. 

25 Ad hoc networking is therefore seen as providing a si^lementary set of inputs/services to 
control/information systems. In some instances, these inputs/services may be 
complementary to one another whereas in other instances they would overlap. For 
instance, in the case where vehicles are IEEE 802.11 -enabled, radar can complement ad 
hoc networking by providing neighbor information for immediate adjacent vehicles: Of 

30 course, if these vehicles are also IEEE 802.1 1-enabled, this functionality overhips that of 
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radar. This provides a degree of redundancy that can only be beneficial to the objective of 
enhanced safety, particularly since the margmal cost of providing services based on IEEE 
802.11 is msignificant^^ 

The increasing use of mobile data communications for remote on-board data acquisition 
5 has given rise to a need for a standard architecture enabling interoperability of modules 
participating in vehicular telemetry across wide area networks. The application with the 
greatest potential for widespread use is wireless On Board Diagnostics (OBD-III), but 
there is a number of other applications, including vehicle maintenance and tracking* The 
paradigm of communications network management, where nodes such as bridges and 

1 0 routers can be remotely diagnosed by a management entity, provides an appropriate model 
for remote vehicular diagnostics. The specifications of the Simple Network Management 
Protocol (SNMP) are therefore used in novel and une}q)ected ways as a basis for deriving 
an Automotive Telemetry Protocol (ATP). ATP operates ia an open Internet envkonment 
that enables client-server relationships between on-board diagnostic "agents'^ and 

15 "monitors" located anywhere in the network- The SSL protocol is layered above this to 
provide security. The same protocol architecture, minus the security, can be layered on 
top of IEEE 802.1 1-based ad hoc networks for application in mtelligent transport systems 
(ITS). 

NETWORK NEIGHBOURHOOD 

20 

The concept of a network neighbourhood has been borrowed as it is used in the 
topological sense to characterize adjacent nodes on a data Imk. If node A can reach 
(transmit to) node B without traversmg a communications bridge, then A and B are said to 
be in the same neighbourhood. This is illustrated in Figure 14, which depicts two data 

25 links connected via a bridge. The data Imk on the right is defined by the IEEE 802.3 
(Ethernet) specification, vAAch is commonly used for wired Local Area Networks (LAN). 
. The data link on the left is specified by IEEE 802.1 1 which is wireless LAN. As shown m 
Figure 14, A, B and C are neighbours on the wireless LAN, whereas D, E, F and G are 
neighbours on the wured LAN. Although this is not clearly shown m Figure 14, the 

30 neighbourhoods of both the wireless and wired LAN's are defined by topological 

Assuming that the vehicle is IEEE 802.1 1-enabled for Wide Area Networking purposes. 
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relationships between the nodes, not by physical distance* If two nodes share the same 
medium and the quality of the signals between them is acceptable (in t^os of enor 
levels), then they are topologically in the same neighbouriiood or adjacent. 

5 In the case of an intelligent highway network neighbourhood, an additional geographic 
criterion can be added, if dedred, to the determination of adjacency. By comparing GPS 
position reports of other nodes oh the data link with its own GPS position, each node can 
filter out other nodes which are outside of a specified geographical threshold and therefore 
not relevant to the opemtion of the vehicle. 

10 

The foregoing description allows up to put forward a definition of an ITS Wi-Fi 
neighbourhood, from the perspective of a single node. 

An ITS Wi-Fi neighbourhood is a collection of surrounding IEEE 802.1 1 nodes, sharing a 
15 common physical medium (i.e. a specified direct sequence spread spectrum channel) as 
well as the timing parameters for medium access control, and within a relative geographic 
position that is significant to the safe operation of a vehicle on any type of public roadway. 

REGISTRATION ON THE NETWORK 

20 

The IEEE 802.1 1 specification defines timing parameters that are used in conjunction with 
a timing synchronization function to coordinate access to the medium; i.e. to mimmize 
contention for the channel and to reduce the possibility of collisions. Nodes cannot use the 
medium to transport data until tiiey have recdved the appropriate "registration" fi»mes 
25 fix)m nodes that are ahready part of the network. Registration firames contain the 
information needed to correctiy operate on tiie medium, including a time stamp allowmg 
the new entry to synchronize with the existing nodes. 

In 802.11, the method used to coordmate access to the medium is called Carrier Sense 
30 Multiple Access with Collision Avoidance (CSMA/CA) which is similar to the method 
used m 802.3 (Ethernet). It is based on the idea of "sniffing** the channel for a carrier prior 
to transmission. If the medium is busy» the node with data to send enters a randomly- 
computed waitmg period before retrying, which nummizes the likelihood of simultaneous 
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retries by multiple nodes waiting for the channel (and the resulting *'gridlock**^t this 
would create). 

The 802.11 specification calls (his a distributed coordination Jimction (DCF). It also 
5 defines a contention-firee mechamsm which is called point coordination /unction (PCF). 
Whereas DCF is the default mode of operation, PCF has been made available to handle 
special scenarios, as in the case of time-critical trafiBc such as audio and video. Typically 
PCF is provided through a fixed access point, which, in the case of ITS| would take the 
form of a roadside base station. 

10 

Vehicles wishing to have access to the Intemet will register with roadside access points 
using the channel(s) allocated for this application^^. The performance criteria for 
streaming audio and video, or for VOIP (Voice Over IP), may require flie PCF method of 
channel management. However, the ad hoc network of vehicles sharing the same 
15 neighbourhood will use DCF to manage its channel(s). Since DCF does not rely on the 
presence of a "master" station to coordinate access to the medium, tiie ad hoc network 
does not require a roadside infrastructure in order to function properly. 

This does not preclude the use of a roadside infirastructure. Even if Intemet access and 
20 other services are optional, base stations may still be requked for a varied of ancillary ITS 
functions, including diSerential GPS beacons, geographic orientation with respect to the 
highway system^^, electromc toll collection, electronic road signage and travel 
information. 

25 The registration mechanism itself can be operated in either a passive or an active mode. 
Both of these methods are described below. 

Passive Repstraiion 

30 In the passive mode, a candidate node listens for a beacon firame from an existing node. In 



See the section entitled Wi-Fi Channel Selection Ibr a discussion of the distribution of channels between 
ITS and Internet functions. 
See Wi-Fi Channel Selection. 
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ad hoc networks, all existing nodes transmit beacon fi'ames periodically, allowing nodes 
entering the network to synchronize with the existing nodes for channel management. A 
beacon frame signals the start of a contention-free period, during which all other nodes' in 
the neighbourhood defer transmissions so that new nodes wishing to announce their 
5 presence can do so. Both the interval between beacon frames and the subsequent 
contention-free period are configurable parameters that are typically set in the ranges of 1- 
2 seconds, and 100 ms - 0.5 seconds, respectively. However, as will be seen in the next 
section, there may be several hxmdred vehicles in the same neighbourhood, particularly in 
congested highway conditions, which would render these settings impossible. Increasing 
10 the interval between beacon frames is only part of the solution. Figure 15 illustrates that if 
every one of 100 vehicles were to transmit beacon frames at intervals of 10 seconds, each 
announcing the start of a 100 ms contention-free period, there would be no time left during 
the 10 second period to transmit any user data. 

15 The complete solution lies in the fact that the ITS ad hoc network nodes do not need to 
negotiate any of the logical management ftmctions of association and authentication, 
specified in the medium access control (MAC) layer of 802.11, Association is the 
mechanism whereby one node requests explicit recognition from another node. In an 
infrastructure network, requests are sent to an access point, which stores the address of the 

20 requesting node in a local table and sends a response frame. The address table maintained 
by the access point controls whether packets destined for specific addresses are actually 
transmitted. If no association has been established for an address, no user data will be sent 
to it 

25 However, as explained fax the section entitled Neighbour Discovery, most of the user data 
in the ITS ad hoc network is sent to the broadcast address (i.e. to all nodes), for which no 
association is required. There are some applications in which associations with 
surrounding vehicles are required but these would be only with the physically adjacent 
vehicles. Each node should only negotiate associations with neighbours inside a prescribed 

30 boundary wherein the driving manoeuvres of those neighbours are significant enough to 

warrant unicast messages (i.e. addressed to specific destination node). Since each node 

will receive a far greater number of beacon frames from neighbours with which it does not 

need associations, the contention-free periods following these beacon frames will be 
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essentially wasted In order to preserve bandwidth, the contention-free period should be 
reduced to a niinimum allowable value (say, 1 ms) and the negotiation of associations 
should be triggered not by the reception of beacon frames, but by conditions determined 
through the Discovery process, which is described in the next section. 

5 

Authentication is the process whereby the requesting node is granted permission to 
communicate usmg a synunetrical mcryption key. In the ITS ad hoc network, 
authentication is not only not required, it is anti-Aetical to the concept of vehicle 
platooning or ''cluster mtelligence** because all parties must necessarily and freely 
1 0 exchange information without restriction. 

Active Registration 

The active registration method enables the candidate node to send probe fi^imes, which are 
15 essentially "ping" requests for some other node to respond. In the ad hoc network 
topology, probes must be broadcast to all . listeners, as there is no single node that can be 
relied upon to always be present (i.e. fixed access point). The IEEE 802.1 1 rule is that the 
response to a probe is sent by the node which transmitted the most recent beacon frame. 

20 The facility of active registration enables us to minimize the use of bandwidth by the 
transmission of beacon frames. Suppose the interval between beacon frames is configured 
to 60 seconds. With a contention*free period of only 1 ms after each beacon frame, a 
platoon of 5 vehicles would use roughly .01 % of the available time for beacon frame 
broadcasts, and a platoon of 500 vehicles would use only 1%, 

25 

The scenario with 5 vehicles is shown in Figures 16a and 16b. Hie average time between 
beacon firames is 12 seconds. iBach vehicle in the platoon is numbered according to its 
sequence position for transmitting beacon frames. Vehicle 6, entering on the access ramp, 
begms transmittmg probe request frames after vehicle 4 transmits its beacon frame, in 
30 order to discover a new ad hoc network^^. Vehicle 4 responds almost inunediately with a 



The new vehicle entering the expressway must know when to try to switch to a new ad hoc networic. As 
discussed in Wi-Fi Channel Selection, specific channels are allocated to vehicular flows on divided 
highways based on heading. We assume that vehicles are not equipped with accurate digital maps and 
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probe response . 
NEIGHBOUR DISCOVERY 

5 The neighbour discovery mechanism is comparable to the concept of neighbor discovery 
protocols used for routing data traffic in network environments with dynamic topologies. 
The method is based on unsolicited neighbor advertisements that incorporate, as explamed 
previously, a geographic component These are periodic messages that each node 
broadcasts containing its GPS information, including latitude, longitude, speed and 
10 heading**. 

The neighbour advertisements are used by each node in the ad hoc network to establish an 
"image", in memory, of the current configuration of the neighbourhood. Figure 17 
illustrates this concqpt, showing the neighboiurhood image formed by the second vehicle in 
15 the passing lane. 

The time mterval between broadcasts^ called the discovery cycle^ must be frequent enough 
to maintain a picture of the neighbourhood that is accurate in terms of the relative position 
of each neighbour. The accuracy of GPS reports, in terms of the relative location of two 

20 nodes in geogn^hic proximity to one another, is much higher than the accuracy of 
absolute GPS reports, since the error inherent in the processing of the satellite signals 
should affect all nodes equally. Therefore, the relative position of each node with respect 
to the other should, theoretically, contain essentially no error, enabling vehicles to judge 
the distances between them with a level of precision that is effective for the tasks of 

25 collision avoidance and platooning. For instance, the position of a vehicle travelling at 70 
mph changes by more than 100 ft/sec. This would si^est a requurement for several 



therefore not able to use GPS to determine whether they are entering divided highways. It is therefore 
necessary to adopt the rule that when the 'forward" region of a vehicle*s neighborhood suddenly becomes 
"depopulated*', the vehicle must begin broadcasting probe frames on all appropriate channels until it receives 
a response from a vehicle with a matching heading. See the section entiUed Changing Neighborhoods. 

Probe response fiames must contend for the ch^el with Neighbor Discovery and other uso- traffic See 
Ae secUons below. 

Elevation may also be required. This would enable receiving vehicles to distinguish vehicles on elevated 
expressways from those at grade level 
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updates per second in order to maintain accuracy. However, the frequency of Yipdates is 
constrained by the amount of data traffic that is generated during the discovery cycle, in 
ord^ to avoid duumel contention^ This, in turn, is a function of the number of vehicles 
that are within SF range, i.e. the neighborhood population. 

5 

It should be recognized, however, that there is a cux^ulac relationship between all of these 
variables. The neighbourhood population is a function of the average speed of the 
sunrounding vehicles. The greater the speed, the smaller the neighbourhood population; 
th^efore the smaller the amount of data traffic in the discovery cycle vMoh allows for a 
10 greater frequency of updates. 

This can be illustrated by example. At 70 mph, the safe stopping distance is roughly 200 
ifeet Assimiing all vehicles respect the recommended stopping distance^^ a maximum RF 
range of 300O ft and a maximiun of four lanes in the same direction^^ the surrounding 
1 5 neighbourhood can contain a maximum of 60 vehicles. 

To determine the total amount of traffic that is transmitted over the spread spectrum 
channel, we must first establish the total, size of each discovery packet. This is shown m 
Figure 18, which describes the protocol stack fiom the physical to the session (ATP) layer. 
20 It is expected that all of the requhred user information above the data link layer (IEEE 802 
Logical Link Control) can be compressed into 8 bytes. The result is a frame size, at the 
Physical Layer Convergence Procedure (PLCP) sublayer of $4 bytes. Therefore, the total 
amoimt of traffic in the discovery cycle is 

25 64 X 60 = 3840 bytes or 30,770 bits. 

At 1 1 Mbps^, the data rate of the spread spectrum channel should be able to support 
several discovery cycles within an mterval of one second, even allowing for some 

This is, of course, one of the ultimate objectives of this technology. 
^ Based on a maxmtmum range of 0.5 kilometers for each transmitter, each node can hear transmissions 
vvithin this radius. The "width" of the neighborhood is therefore 1 kilometer or approximately 3000 ft. 

Vehicles travelling in the opposite direction or in acyacent "collector** or "express" streams, do not transmit 
discoveiy frames on the same channel. See Wi-Fi Channel Selection. 

^ For Reasons explained in Channel Selection , the data rate of channels using ad hoc networking would 
more likely be 2 Mbps, which is still expected to be sufficient for several discovery cycles per second. 
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degradation of throughput due to channel contention with such a relatively large number 
of nodes. 

In Older to compensate for this change, the event queue of the "cluster intelligence" 
S process should include a periodic timer that drives an update of the position of all vehicles 
in the neighbourhood, based on the speed and heading rq)orted in then: last broadcasts. 

Filtering Neighbour Advertisements 

10 Each node can limit the population of its neighboutfaood such that only those neighbour 
that are close enough to have a potential impact on the safe operation of the vehicle are 
included. By filtering out node beyond this boimdary, the size of the collections of 
neighbour "objects" in memory are restricted and the amount of processing necessary to 
periodically update any state variables belonging to these objects are Umited. 

15 

Message Compression 

It has been stated that the GPS discovery message can be compressed into 8 bytes. This is 
accomplished by incorporating only the least significant 2 bytes of both the latitude and 

20 longitude^. These 2 bytes represent the jfractional part of the minutes portion of the 
reading. This is sufficient since one minute of latitude or longitude is greater than one 
mile, which .is well beyond the maximum RF range of 0.5 kilometers. Therefore, a 
receiving node can easily reconstruct the GPS position' of tiie transmitting node by 
substituting the degrees and minutes of its own GPS position for both latitude and 

25 longitude. It must also increment or decrement tiiese values where appropriate near 
measuremmt boundaries. For instance, if a receiving node has latitude of 43 degrees and 
56.9982 minutes, whereas the message received indicates a finctional value of .0053 
minutes, the minutes value substituted should be 57 instead of 56. 

30 Figure 19 illustrates the format of the complete GPS discovery message. The speed is an 
integer value firom 0 to 255 (one byte) and the heading is from 0 - 360 (9 bits) with 7 bits 



^ The size of this message increases to 10 bytes if elevation is included. 

• 43 

SUBSTITUTE SHEET (RULE 26) 



wo 02/31793 PCT/CAOl/01420 

of Pactional degrees* The leading byte indicates, in the most significant bits, the channel 
to be used by tiie sender for broadcast on the next discovery cycle. This is explained in the 
following-section. The other bits of the leading byte are reserved for future use. 

S Wi-Fi Channel Selection^ 

The 802.11 specification for mobile applications calls for at least 3 channels of direct 
sequence spreading (PSS) which can operate concurrently without interference. However, 
through software-based configuration of the transmitter, more channels can be obtained at 

10 lower data rates. For uistance, by allocatmg a smgle 11 Mbps channel for high speed 
intemet access, a larger number of at least six 2 Mbps channels can be obtained from the 
remaining bandwidth. This allows mobile nodes to separate ad hoc networking data traffic 
from infirastructure-based data trafiQc that uses roadside access points. Since there is no 
need for communications between vehicles on opposite sides of a median, it suffices for 

IS each node to monitor the channel used to broadcast discovery messages by all other nodes 
travelling in the same direction. 

In order to avoid uxmecessary channel contention between vehicles travelling in opposite 
directions, the channel selection for discovery broadcasts can be determined on the basis 

20 of heading, A simple scheme would be to allocate 4 of the 10 channels for ad hoc 
networking and to divide the compass into four quadrants^^. However, as Figure 20 shows, 
this would not handle the case where a slight curvature of the roadway would result in a 
following vehicle listening to a channel on which the leading vehicle is no longer 
transmitting. This can be resolved by fl^gmg the discov^ message in a way that 

25 mdicates to neighbours on what channel the next message will be transmitted. 

In other words, when a vehicle detects that its heading has shifted into a different 
quadrant, it should not immediately begin transmitting on the correspondmg channel. The 

^ This section describes the use of the channels available under the specification for the unlicensed 2.4 GHz 
band. This specification is entiUed IEEE 802.11(b). The use of the IEEE 802.1 1 MAC with other 
fi-equency bands, such as the 5.9 GHz band allocated by the FCC for intelligent highways, may prescribe 
different modulation and channelization techniques sudi that the number of channels available may be 
difiEbrent. Howev^, the notion of allocating the channels available to various IVHS functions would not 
. change. 

" An additional channel should be allocated for use by all vehicles on non-divided highways and city streets. 
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next message is transmitted on the current channel but all listeners are advised of the 
channel that will be used on the subsequent message^^. Only the following vehicle should 
switch to monitoring the new channel It should also switch if it detects the heading 
change before it receives the change of channel flag from the vehicle ahead. 

5 

This vehicle enters a transitional phase where it may monitor a different channel than the 
one on which it transmits. During this period, the next following vehicle will recdve 
messages only from neighbours transmitting on the "old" channel (i.e. prior to the 
curvature in the road). It will not receive any Discovery messages. More importantly, it 
10 will not receive any asynchronous event reports from several vehicles ahead in the 
platoon. In order to compensate for this, it needs to continuously scan both the "old" and 
the "new" channels until it receives a "next channel" flag from the vehicle ahead of it. 

Changing Neighbourhoods 

15 

To establish the conditions under which a vehicle changes neighbourhoods, reference is 
made to the definition of an ITS Wi-Fi neighbourhood given earlier. The neighbourhood 
changes when there is a change in the shared medium. An example of such a change has 
already been described, when the roadway heading shifts to a new compass quadrant and 
20 there is a staged transition of the platoon to a new Wi-Fi channel. 

In order to address this issiie, the following question needs to be answered: how does a 
vehicle determine that it is entering an expressway without requiring the use of detailed 
digital maps? The solution is simple if the vehicle is following another one that is entering 
25 the expressway. It is the leading vehicle's problem! The following vehicle simply needs to 
monitor the current channel for a "next channel" flag from the leading vehicle. Of course, 
this is a facile solution since it shifts the problem to the leading vehicle and besides, it 
does not address the scenario where there is no leading vehicle that is currently within the 
neighborhood. 

30 ' 

The answer is provided by the mechanism for active network re^stration using probe 

Note also that the subsequent message cannot be transmitted until re^sfration on the new channel has 
taken place using probe frames. 
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frames. When a vehicle detects that it has no one ahead of it, it must begin to probe 
whichever of the four, channels allocated to the quadrants of the compass in which the 
vehicle's current headmg &lls. Until it receives a* response from some node on the new 
channel, it should continue to monitor the existing channel used for undivided highways 
S and city roads. One of two possibilities will occur. 

• new neighbours are foimd (througih the discovery mechanism on the existmg channel). 
These could be moving either in the same or the oncoming direction. Or even in a 
transversal direction. Their locations preclude the possibility that the vehicle is on an 

10 access ramp to an expressway. In this case, the vehicle ceases the periodic probes. 

• a probe response is received on the new channel. The vehicle must prepare to switch 
channels and notify all its current neighbours that it is doing so by setting the "next 
channer flag in its next discovery message. 

15 

• This scenario is reversed in the case where a vehicle leaves a divided expressway. 
Service Advertisements 

20 There may be cases where specialized nodes may provide streams of information that 
would be costly, in terms of bandwidth, to broadcast in an unsolicited fashion. Instead, 
these nodes can advertise the availability of such services by periodically broadcasting a 
message notifying all listeners that the service is available upon request Examples of this 
would be a digital video camera mounted on board a vehicle or on a traffic signalization 

25 light 

APPLICATIONS 

Safety vs. Congestion Management 

30 

The application of ad hoc networks to ITS tasks has value in terms of both road safety as 

well as traffic management aimed at reducing congestion. In some respects, there is an 

artificial distinction between these areas. Better traffic management should result in better 

safety, and vice versa. The descriptions of the following application areas do not 
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distinguish between these two purposes. 
Event Notificatioti 

5 All nodes participating in an ad hoc ITS network are reqtiired to inform their neighbours 
of any operational events that may be significant to a neighbouring vehicle, such as 
acceleration, brake application, turn or lane change, etc. These evmts should be reported 
as asynchronous notifications sent to the broadcast address. In other words, any neighbour 
that is listening should receive a real-time notification of the event. For instance, 

10 application of the foot brake would be reported not only to the following vehicle behind 
but to every other vehicle in the following platoon. The reaction time to a brake light (if it 
is working) is typically in the range of 0.5 seconds. Therefore, if the vehicle at the head of 
a platoon of seven vehicles applies the foot brake, the vehicle at the end of the platoon 
could receive notification as much as 3 seconds before seemg the brake lights of tiie 

1 5 vehicle in firont of it 

Ail asynchronous event notifications should be repeated up to n times, where n is a 
configurable parameter of die IEEE 802.11 NOB (Management Information Base). 
Repetition of event notifications will ensure that following neighbours required to listen to 
20 more than one chaimel (during the transition phase described in Wi_Fi Channel Selection) 
will have an opportunity to hear the message. 

Intention Notification 

25 The ad hoc network provides the means for vehicle-to-vehicle notification of intention 
with respect to driving maneouvres. A class of such notifications can be specified that 
require explicit acknowledgements fi:om the receiver of the notification. (Acknowledged 
Connectionless Service of the LLC layer) These correspond to Set commands that can be 
issued through the use of an ATP client service. By acknowledging these notifications, the 

30 receiver informs the sender that it is "aware" of the sender's intentions. The state of 
knowledge of both parties can then become inputs to their respective control or cockpit 
' electronic information systems. 

47 



SUBSTITUTE SHEET (RULE 26) 



wo 02/31793 



PCT/CAOl/01420 



Pass 

Figure 21demonstrates an example of a driving maneouvre that can be assisted by ad hoc 
networking. The speed of vehicle A in the passing lane is greater than that of vehicle B in 
S the slow lane. Assuming that the speed of B remains constant, A can determine how much 
time remains before it passes B, using its own speed and the neighborhood position of B. 
When the remainmg time equals the time interval required for advance notification (Ax), A 
sends k imicast firame to B containing a notification of intention to pass on the left If B 
responds with an acknowledgement, A is therefore able to provide tiie appropriate control 
10 or driver information system vnth a confirmation that the vehicle to be passed is "aware** 
of the intentions. 

Lane Change 

15 The intention to change lanes can be announced and acknowledged in a manner similar to 
the intention to pass. The vehicle preparing to change lanes issues its notification to the 
closest following vehicle in the lane to v^ch it intends to change. Again, both parties are ' 
aware and prepared for the manoeuvre. 

20 Merge/neld 

One of the most interesting potential applications of ad hoc networking is the management 
of lane mergers and yielding on access ramps and lane closure on expressways* As 
illustrated in Figure 22, both the yielding and the merging vehicles are aware of each 
25 otfa^s location and speed, which provides their respective coclq)it electronic information 
systems with uiputs to assist the driver in a smooth adjustment to the new conditions. 

Intelligent Traffic Signalization/Qighway Information Systems 

30 Discussed herein above is the capability of Wi-Fi to support concurrent ad hoc networking 
and infrastructure-based commxmications. Whereas intelligent traffic lights would be part 
of the roadside infrastructure, they would need to use the channels allocated for ad hoc 
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networking in order to be effective, since it is only these channels that are regularly 
monitored by vehicles* Using Wi-Fi, an intelligent traffic light could, for example: 

• transmit a '^yellow light" notification to approaching vehicles 

• alert vehicles in the transversal direction of oncoming traffic at high speed^^ 

• identify vehicles that run red lights^* 

On the other hand, highway information systems (electronic signage, automated toll 
collection, etc) should not operate on the ad hoc channels (unless it can be detomined that 
substantial bandwidth remains even under ttie most congested driving conations). 
Vehicles could monitor these infiiastructure channels as mitiated and termmated by driver 
input functions. 



" If oncoming vehicles are not equipped witii Wi-Fi but the trafficlight can detect them with radar. 

The traffic light would request the registration from the vehicle that ran through the light The request 
would be authenticated, at the ATP level, as coming from an authorized client If fact, tiiis would create a 
deterrent that would probably eliminate the problem entirelty.' 
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CLAIMS 

1. A method of conveying vehicle operation data fiom a vehicle to a remote momtoring 
recipient, comprising the steps of: 

5 * establishing a data link between the vehicle and the remote monitoring 

recipient; 

- coUectmg vehicle operation data from data sources in the vehicle; 

10 - packaging the vehicle operation data m a data packet using protocol derived 

from SNMP; and 

- conveying the data packet over the data link. 

15 2, A method of convejdng vehicle operation data from a vehicle server to a remote 
monitoring client, comprisix^ the steps of: 

- establishing a data link between the vehicle and the remote momtoring client; 
20 - collecting vehicle operation data from data sources in Ifae vehicle server; 

- packaging the data in a protocol data unit having a protocol data unit payload, 
the payload includuig a plurality of VARIABLE BINDING fields, each 
VARIABLE BINDING field having an OBJECT IDENTIFIER field of two 

25 bytes, a VALUE TYPE field of one byte and a VARIABLE BINDING value 

of a size according to the VALUE TYPE field ; and 

- conveying the protocol data unit over the data Imk. 

30 3. A method of collecting vehicle operation data from a vehicle for later transmission to a 
remote monitoring recipient in a manner to minimize the bandwidth requirements for 
the later transmission, comprising the steps of: 
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- providing a vehicle on-boaid computing device; 

- providing a number of data acquisition modules, each to measure one or more 
S operating characteristics of tiie vehicle, the operating characteristics 

correspondmg to current values of a set of managed objects; 

- interfacing the vehicle on-board computing device ivith each of the data 
acquisition modules; 

10 

- configuring the vehicle on-board computing device to: 

a) form a diagnostic information base for receiving and storing values for 
each of the managed objects from each of the correspondmg data 

1 5 acquisition modules; 

b) assemble an event report based on information contained in the 
diagnostic information base; and 

20 c) package the event report in a protocol data unit accgrding to an SNMP- 

derived protocol 

4* A method as defined m claim 3 wherein tiie operating characteristics include GPS 
position, engme speed, road speed, or engine temperature, or an OBD-II parameter 
25 related to vehicle emissions. 

S. A method as defined in claim 4 wherein the OBD-II parameter includes misfire 
detection. 

30 6. A method as defined in claim 3, fiirtfaer comprising the step of enabling the vehicle on- 
board computing device to: 

a) establish a data link with the remote monitoring recipient; and 
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b) convey the protocol data unit over the data Imk. 

7. A method as defined in claim 6» further comprising the step of enabling the remote 
monitoring recipient to issue a GET protocol data imit to retrieve the ciment values for 

5 a specific set of managed -objects firom the vehicle on-board computing device. 

8. A method as defined in claim 7 further comprising the step of enabling the remote 
monitoring recipient to wait for an acknowledgement to the GET protocol data unit by 
the vehicle on-board computing device. 

10 

9. A method as defined in claim 6, fijr&er comprising the step enabling the vehicle on- 
board computing device to issue a TRAP protocol data unit to report a vehicular event 

10. A method as defined in claim 9 further comprising the step of enabling the vehicle on- 
1 S board computing device to: 

a) store threshold values or a reporting interval for each vehicular event; and 

b) issue each TRAP protocol data unit, either when a threshold value has been 
20 exceeded or at a corresponding reportmg interval. 

1 1. A method as defined in claim 10 wherein the TRAP protocol data unit reports a GPS 
position. 

25 12. A method as defined in claim 6, fiuther comprismg the step of issuing an INFORM 
protocol data unit firom the vehicle to report an raceptional vehicular event 

13. A method as defined in claim 12, further comprising the step of enabling the vehicle 
on-board computing device to: 

30 

a) store any one of a plurality of specified exceptional vehicular events in the 

diagnostic information base, including one or more regulatory exceptions, 

maintenance exceptions or operational exceptions; and 
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b) issue the INFORM protocol data unit when any one of the specified events 
occurs. 

5 14. A method as defined in claim 13 wherein the INFORM protocol data unit is sent as a 
result of a regulatory threshold level being exceeded, 

15. A method as defined in claim 13 further comprising the step of enabling the vehicular 
onboard computing device to wait for a confirmation that a previous INFORM 

1 0 protocol data unit has been logged in a data base by the remote monitoring recipient 

16. A method as defined m claim 15, fiirther comprising the step of re-transmitting the 
INFORM protocol data imit in the absence of a confirmation that a previous INFORM 
protocol data unit has been logged in a database by the remote monitoring recipient. 

15 

17. A method as defined in claim 6, fiuther comprising the step of enabling the remote 
monitoring , recipient to issue a SET protocol data unit to the vehicle on-board 
computing device to set one or more of the managed objects. 

20 18. A method as defined in claim 6, wherein the data link is wireless and includes an 
radio fi:equency band under the IEEE 802.11 standard, a satellite RF packet network 
or a teixestrial RF packet network. 

19. A method as defined in claun 6 wherein the protocol data unit is a REQUEST 
25 protocol data unit, the protocol data unit excluding the ERROR STATUS and ERROR 
INDEX fields of the SNMP protocol. 

20; A method as defined in claim 6 wherein the protocol data unit excludes the LENGTH 
field of each variable binding of the SNMP protocol. 

30 

21. A method of conveymg vehicle operation data from a vehicle to a remote monitoring 
recipient, comprising the steps of: 
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- establishing a data link between the vehicle and the remote monitoring 
recipient; 

- collecting vehicle operation data fiom data sources in the vehicle; 

- packaging the vehicle operation data in a data packet using protocol derived 
from SNMP; and 

- conveying the data packet over the data Imi^ the protocol data unit being issued 
in response to a request by the remote monitoring recipient and containing both 
the request and requested values in the request and being encapsulated within a 
single message and in a single unfragmented network packet. 

22, A method of collecting vehicle operation data from a vehicle for later transmission to 
a remote monitoring recipient in a manner to minimize the bandwidth requirements 
for the later transmission, comprising the steps of: 

- providmg a vehicle on-board computing device; 

- -providuig a number of data acquisition modules, each to record a current value 
of a managed object of the vehicle; 

- inter&cing the vehicle on-board oomputmg device with each of the data 
acquisition modules; 

- configuring the vehicle on-board computing device to: 

a) foim a diagnostic information base for receiving and storing values of 
the managed objects from each of the datK acquisition modules; 

b) assemble an event report based on mformation contamed in the 
diagnostic information base; and 
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c) package the event report into a protocol data unit, the protocol data unit 
including a protocol data unit payload having a plurality of VARIABLE 
BINDING fields, each VARIABLE BINDING field having an OBJECT 
IDENTIFIER field of two bytes, a VALUE TYPE field of one byte and a 
VARIABLE' BDSfDINO value of a size according to the VALUE TYPE 
field. 

23/ A method as defined in claim 22 wherem the protocol data unit mcludes a header 
havii^ a PDU TYPE data element with a value corresponding to one of a set of 
values, the set including a GET value, a SET value, a TRAP value, an INFORM value 
and a RESPONSE value. 

24. A computer implemented system for conveying vehicle operation data firom a vehicle 
to a remote monitoring recipient, comprising: 

- an vehicle on-board computing device in communication with a number of 
vehicle operation data sources in the vehicle; 

- a wireless communications device for establishing a wireless data link with the 
vehicle on-board computing device and the remote monitoring recipient; 

- the vehicle on-board computing device being enabled to package the vehicle 
operation data in a data packet using protocol derived firom SNMP for 
transmission to the remote monitoring recipient over the wireless data link. 

25. A computer-readable data structure for collecting and conveying vehicle operation 
data from a vehicle to a remote monitoring recipient, comprismg: 

" an application module for receiving vehicle operation data from a nimiber of 
data sources in the vehicle; 

-a storage module for storing a diagnostic information base, the diagnostic 

information base includmg a number of managed objects for a number of 
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vehicle operation parameters and a number of values for each of the managed 
objects; and 

- a communication module for conveying protocol data tmits under a protocol 
derived from SNMP over a wireless data link to the remote monitoring 
recipient 

26 A computer program product encoded in a computer readable medium including a 
plurality of computer executable steps for a computer on*-board a vehicle for 
collecting and conveying vehicle operation data from the vehicle to a remote 
monitoring recipient, comprismg: 

- receiving vehicle operation data fiom a number of data sources in the vehicle; 

- storing, in a diagnostic information base, a plurality managed objects for each 
of a number of vehicle operation parameters and a plurality of values for each 
of the managed objects; 

- establishing a wireless data link between the computer and the remote 
monitpring recipient 

- conveying a number of protocol data units under a protocol derived fiom 
SNMP over a wireless data link to the remote monitoring recipient 

27. A signal propagated on a carrier medium, the signal including a packaged prototol 
data unit containing a payload encoding predetermined operational data of an 
automotive vehicle, according to a protocol derived fiom SNMP. 

28. A signal as defined m claim 27, tiie payload includmg a plurality of VARIABLE 
BINDING fields, each VARIABLE BINDING field having an OBJECT 
IDENTIFIER field of two bytes, a VALUE TYPE field of orie byte and a VARL^BLE 
BINDING value of a size accordmg to the VALUE TYPE field data unit. 
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29. A signal as deiBned in claim 27 wherein the payload includes a GPS position segment, 
a GPS heading segment, a vehicle speed segment or an OBDII vehicle emissions 
segment 

30, A system for conveying vehicle operation data £:om a vehicle to a remote monitoring 
recipient, comprising: 

- vehicle on-board computing means in communication with a number of vehicle 
operation data source means in the vehicle; 

- wircless communications means for establishing a wireless data link with the 
vehicle on-board computing means and the remote monitoring recipient; 

- the vehicle on-board computing means being enabled to package the vehicle 
operation • data m a data packet using protocol derived from SNMP for 
transmission to the remote monitoring recipient over the wireless data link. 

31. A method of conveying vehicle operation data from a vehicle to a remote monitoring 
recipient, comprising: 

a step for establishing a data link between the vehicle and the remote 
monitoring recipient; 

^ - a step for collecting vehicle operation data from data'sources in the vehicle; 

- a step for packaging the vehicle operation data in a data packet using protocol 
derived from SNMP; and 

* a step for conveymg the data packet over the data link. 

32, A communications network for exchanging data between a pliu-ality of vehicles, 

comprising a computmg unit onboard a corresponding vehicle, wherein the computing 

unit in a given vehicle is operable to broadcast identity messages and to receive 

equivalent identity messages from other vehicles in an adjacent region, where said 
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messages are used to identify the neighbouring vehicles in the network for exchanging 
data with selected oiies of the vehicles thereiiu 

33. A networic as defined in claim 32 wherein the computing unit is operable to update a 
S list of neighbouring vehicles and wherein the inherent error in said GPS infohnation is 

constant across all network nodes so that a neighboriiood geography can be 
established in t^ms of relative, instead of absolute, positions, 

34. A network as defined in claim 33 wherein the computing unit adds new neighbour 
10 vehicles to tiie list as identily messages are received from new vehicles entering the 

region. 

35. A network as defined in claim 34 vAierein the computing unit deletes a given 
neighbour vehicle ftom the list when identily messages aip* not received fix>m the 

1 S given neighbour vehicle after a predetermined period of time. 

36. A network as defined in claim 35 wherein the computing unit deletes a given 
neighbour vehicle vehicles from the neighbour database when identity messages 
received from the given neighbour vehicle indicate that the neighbour vehicle is 

20 leaving or has left the adjacent region. 

37. A network as defined in claim 33 wherein the medium of coihmunications is a high 
frequency channelized RF band and its use by each of said computing units is 
controlled according to the IEEE 802.1 1 Medium Access Control C^1AC) protocol. 

25 

38. A network as defined in claim 33 wherein said computing units are Internet 
addressable. 

39. A network as defined m claim 33 wherein said computing units are IPv6 addressable. 

30 

40. A network as defined in claim 33 wherein said computing units exchange data using 
an SNMP-derived protocol. 
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41. A networic as defined in claim 33 wherein the identity messages include GPS 
information and the IEEE 802. 1 1 MAC address of the sender. 

j 

42. A netwoik as defined in claim 40 wherein the OPS infonnation includes latitude, 
5 longitude, speed and heading infonnation. 

43. A network as defined in claim 42 wherem all vehicles in the neighbourhood broadcast 
their identity messages over a discovery time period that is sufficient to allow any 
^ven vehicle to recogDize all its neighbours. 

• 10 

44. A networic as defined in claim 43 wherein channel selection for transmission of at' 
least some messages is based on GPS heading. 

45. A netwoilc as defined in claim 44 wherein both the length of the discovery period and 
15 the geographic size of the region may be adjusted in proportion to the avemge speed 

of the vehicles in the neighbourhood. 

46. A network as defined in claim 43, wherein each of said computing units further 
comprise a transmitter and receiver capable of transmitting and receiving messages 

20 under an SNMP protocol. 

47. An automotive vehicle as defined in claim 32. 

48. A data structure comprismg a speed segment, a headmg segment and position 
25 segment. 

49. A data structure as defined in claim 48 wherein the position segment includes a 
longitude portion and a latitude portion. 

50. A signal propagated on a carrier medium, the signal, mcluding a speed segment, a 
30 heading segment and a position segment 

5L A signal as defined in claim SO wherem the position segment includes a longitude 
portion and a latitude portion. 
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52. A vehicle comprising an onboard computing unit operable to receive messages from 
other vehicles in an adjacent region for assembling a neighbourhood list for 
exchanging data with selected ones of the vehicles listed therein. 

5 

53. A computer program product for operating a programmable computer system on 
board a motor vehicle, comprising a computer readable medium including the 
compiiter executable steps of receiving messages from other vehicles in an adjacent 
region and of assembling a neighbourhood list for exchanging data with selected ones 

10 ofthe vehicles listed therein. 

54. A motor vehicle comprising an onboard general purpose computer and a spread 
spectrum radio, the spread spectrum radio operable to establish a data link with a 
radio in at least one other neighbouring vehicle, wherein the computer is operable to 

15 record messages from at least one other vehicle in an adjacent region for assembling a 

neighbourhood list, and to identify at least one vehicular event from data received on 
the data link. 

55. A computer-readable data structure for collecting and conveying vehicle operation 
20 data from a vehicle on-board computing device and a remote monitoring recipient, 

comprising: 

- a module for indexing a services of protocol values and corresponding requests 
and responses for data exchange between the vehicle on-board computing 

25 device and the remote monitoring recipient; 

- a module for indexing a series of managed objects for a number of operating 
characteristics of the vehicle; 

30 - a module for recording values for each of the managed objects. 

56. A data structure as defined in. claim 55, further comprising a module for indexing 

an identity for each remote monitoring recipient. 
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57. A data structure as defiiied in claim 56, fiiiflier comprising a module for indexing a 
list of one or more managed object conditions for each remote monitoring recipient . 
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